Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add win32-2.6.2.0 to stack.yaml #706

Closed
wants to merge 3 commits into from
Closed

Conversation

oneEdoubleD
Copy link
Contributor

This PR allows the node to build on Windows 10 using stack build by adding win32-2.6.2.0 to stack.yaml.

@oneEdoubleD
Copy link
Contributor Author

Evidence of build:

Building all executables for `cardano-tx-generator' once. After a successful build of all of them, only specified executables will be rebuilt.
cardano-tx-generator-1.7.0: configure (lib + exe)
cardano-tx-generator-1.7.0: build (lib + exe)
cardano-tx-generator-1.7.0: copy/register
Building all executables for `cardano-node' once. After a successful build of all of them, only specified executables will be rebuilt.
cardano-node-1.8.0: configure (lib + exe)
cardano-node-1.8.0: build (lib + exe)
cardano-node-1.8.0: copy/register
Completed 120 action(s).
Log files have been written to: C:\Users\hey\Github\cardano-node\.stack-work\logs\

@dcoutts
Copy link
Contributor

dcoutts commented Mar 24, 2020

What version was it picking before? I don't understand how it was possible to pick an older one, since ouroboros-consensus already specifies a constraint of Win32 >= 2.6.2.0.

@dcoutts
Copy link
Contributor

dcoutts commented Mar 24, 2020

The stack allow-newer: true does not do what the name suggests 🤦‍♂️

From the stack docs:
https://docs.haskellstack.org/en/stable/yaml_configuration/#allow-newer

Note that this also ignores lower bounds. The name "allow-newer" is chosen to match the commonly used cabal option.

Except that the equivalent cabal option actually does do what it says. Furthermore, the cabal version allows for fine grained control.

Note how the cabal.project file for this project has:

allow-newer: katip:Win32

So it only ignores upper bounds, and only on katip and only for the Win32 dependency.

With the stack "allow-newer" feature it removes all the safety checks. All packages, all dependencies, both upper and lower bounds. This is dangerous. In this PR we're working around the problem that it is ignoring an important lower bound.

We should remove the use of allow-newer in the stack files because it masks other problems since it cannot be used selectively.

For the specific case of katip, we can use this git version where our PR to relax the Win32 constraint has been applied. Soostone/katip@0d735de

@oneEdoubleD
Copy link
Contributor Author

After reinstalling the Haskell Platform to try and get around a cabal error my previously working stack build is no longer working due to another error:

Progress 42/125

--  While building package socks-0.5.6 using:
      C:\sr\setup-exe-cache\x86_64-windows\Cabal-simple_Z6RU0evB_2.4.0.1_ghc-8.6.5.exe --builddir=.stack-work\dist\e626a42b build --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
    Process exited with code: ExitFailure 1
    Logs have been written to: C:\Users\hey\Github\cardano-node\.stack-work\logs\socks-0.5.6.log

    Configuring socks-0.5.6...
    Preprocessing library for socks-0.5.6..
    Building library for socks-0.5.6..
    [1 of 7] Compiling Network.Socks5.Parse ( Network\Socks5\Parse.hs, .stack-work\dist\e626a42b\build\Network\Socks5\Parse.o )
    [2 of 7] Compiling Network.Socks5.Types ( Network\Socks5\Types.hs, .stack-work\dist\e626a42b\build\Network\Socks5\Types.o )
    [3 of 7] Compiling Network.Socks5.Conf ( Network\Socks5\Conf.hs, .stack-work\dist\e626a42b\build\Network\Socks5\Conf.o )
    [4 of 7] Compiling Network.Socks5.Wire ( Network\Socks5\Wire.hs, .stack-work\dist\e626a42b\build\Network\Socks5\Wire.o )

    Network\Socks5\Wire.hs:15:1: warning: [-Wunused-imports]
        The import of `Control.Applicative' is redundant
          except perhaps to import instances from `Control.Applicative'
        To import instances alone, use: import Control.Applicative()
       |
    15 | import Control.Applicative
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^

    Network\Socks5\Wire.hs:23:1: warning: [-Wunused-imports]
        The import of `Network.Socks5.Parse' is redundant
          except perhaps to import instances from `Network.Socks5.Parse'
        To import instances alone, use: import Network.Socks5.Parse()
       |
    23 | import Network.Socks5.Parse as P (anyByte, take)
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    [5 of 7] Compiling Network.Socks5.Command ( Network\Socks5\Command.hs, .stack-work\dist\e626a42b\build\Network\Socks5\Command.o )

    Network\Socks5\Command.hs:25:1: warning: [-Wunused-imports]
        The import of `Control.Applicative' is redundant
          except perhaps to import instances from `Control.Applicative'
        To import instances alone, use: import Control.Applicative()
       |
    25 | import Control.Applicative
       | ^^^^^^^^^^^^^^^^^^^^^^^^^^
    [6 of 7] Compiling Network.Socks5.Lowlevel ( Network\Socks5\Lowlevel.hs, .stack-work\dist\e626a42b\build\Network\Socks5\Lowlevel.o )

    Network\Socks5\Lowlevel.hs:10:1: error:
        Could not find module `Network.BSD'
        Use -v to see a list of the files searched for.
       |
    10 | import Network.BSD
       | ^^^^^^^^^^^^^^^^^^

I'll take another look at this later on, but will close the PR for now in case of unintended consequences of the stack file changing for Linux systems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants